[Previous] [Next] [Index]
[Thread]
Comments on the new SHTTP draft of July, 1995
Generally, some good improvements over the old version (though a list
of changes would be useful for tracking things.) However, we don't
progress by exchanging compliments, so here are the criticisms. :-)
Some of these things are nit-picking to ensure there won't be
unneeded incompatibilities if/when this is folded into a subsequent
version of HTTP. Needless to say, every comment should be preceeded
by "In my opinion" or some other weasel words.
****
Section 2.1 still suggests all case variations of the request-line be
accepted. This flies in the face of the HTTP spec (sec 5.2) in which
methods are case-sensitive (and my reading of 3.1 is that version
labels are also expected to be case-sensitive.) I suggest altering
2.1 to read something like:
For HTTP requests, we define a new HTTP protocol method "SECURE".
All secure requests (using this version of the protocol) should
read:
SECURE * SECURE-HTTP/1.1
As with HTTP in general, the request-line should be considered
case-sensitive; however, for compatibility with earlier versions of
this specification, it is recommended that implementations accept
all case variations. The asterisk shown here [ ... ]
(section 2.2 probably should have an analagous change.)
***
Section 2.3.2 still seems just a little bit off with regard to
defining encodings. I suggest it be changed to read as follows:
2.3.2. Content-Transfer-Encoding
The PKCS-7 message format is designed for an 8-bit clean connection,
but may be passed over other channels using an encoding such as
base64 (see RFC 1521 for a description of base64.) Since HTTP is
8-bit clean, however, such encoding is not needed.
For 'Content-Privacy-Domain: pkcs-7' acceptable values for this
field are 'base64' and 'binary'. For compatibility with older
versions of this standard, the value '8bit' should be accepted as
identical to 'binary' but is deprecated.
For 'Content-Privacy-Domain: pem' the message structure is already
encoded for 7-bit transport; therefore, any identity encodings
('7bit', '8bit' or 'binary') are appropriate, although '7bit' is
preferred.
As with HTTP, a default value of 'binary' is assumed if this header
is omitted.
***
In section 2.3.4, the <CoveredDEK> is not adequately defined. More
detail is needed, either here or in section 4.4.7 where
symmetric-header-algorithms are defined, about what padding mechanism
is employed when the symmetric-head-algorithm is a block cipher.
I'm assuming the standard padding mechanism defined in section 6.2 of
PKCS-5 (and also in RFC 1423) is used (being generalized for
algorithms with block sizes larger than 8 bytes.) I think it's obvious
that this is what most people would do in an implementation, but it
probably should be explicit since it isn't defined elsewhere as it is
for the contents.
If my understanding and memory are correct, we can't ignore this,
because some symmetric-content-algorithms (like RC4) have a variable
key length and don't contain information on the effective key length
in the ContentEncryptionAlgorithmIdentifier. Even without this, you
need to be able to tell the precise length of the covered key in order
to do MACs with a key-spec of "dek".
***
In section 2.4, in the second paragraph, "8BIT" should read "BINARY".
The "---BEGIN [...] ---" and "---END [...] ---" lines aren't really
needed; I'd suggest dictating that implementations should not complain
if they're absent. Both HTTP and the BER structure of a PKCS-7
message make it clear where the beginning and end is; more labeling
isn't needed.
***
Speaking of where the end of a secure message is, that brings up the
issue of Content-Length: headers. In general, HTTP requires one be
included in requests so that the server can tell where the request
ends and it should begin its response. With SHTTP, however, this is
not necessarily needed, because both PEM and PKCS-7 have internal
formatting sufficient to determine where the message ends.
So, is the Content-Length: header mandatory on SHTTP/1.1 requests or
not? It would be nice if it were not, since it makes it impossible to
generate requests in a single pass, but that means requiring that
servers be smart enough to use the BER or PEM information to see where
things end. Either way, the spec should probably mention it.
***
Sections 4.4.6 and 4.4.7 dictate that symmetric ciphers with
variable-length keys must have a range specified per section 4.3, but
other variable-length algorithms (i.e. RSA) don't have such a
requirement. Seems to me it should be one or the other; I don't see
an overwhelming reason to force explicit ranges for RC2 and RC4 rather
than allowing the implicit ranges from sec 4.3:
Using simply <cipher> for such a cipher shall be read as the
maximum range (with preferences interpreted [MAX-MIN]) possible with
the given cipher.
***
In section 4.4.11, the phrase "(these may be negotiated downward or
upward)" is not sufficiently precise. For example, consider the
Symmetric-Content-Algo. The default orig is "orig-optional=DES-CBC".
If I include a header of "orig-optional=rc2-cbc[50]" does that mean it
is optional *as well as* the default, or *instead of* the default?
Consider the following two headers:
SHTTP-Symmetric-Content-Algorithm: orig-optional=rc2-cbc[50]
SHTTP-Symmetric-Content-Algorithm: orig-optional=rc2-cbc[50];
orig-refused=des-cbc
Are they equivalient, or different? I believe it is possible to read
the current spec either way.
***
In section 5.1, I don't quite understand the purpose of making
Security-Scheme: mandatory with all messages. Is the intent to use
this to advise that one can handle SHTTP if desired? If so, it seems
likely that trying to incorporate into something more general, like
the HTTP-Extensions mechanism, is worth at least considering.
***
In section 5.4, I don't understand the purpose of the lifetime value
"this". What is it good for? Why would one use it?
The two sentences:
'reply' indicates that it is useful for a reply to this message (or
the duration of the connection, for future versions of HTTP that
support retained connections.)
and
The 'reply' lifetime indicates the key is good for at least one (but
perhaps only one) dereference of this anchor.
seem to contradict each other. I suggest the latter be retained and
the former nixed. The meaning of "this anchor" in this context is,
however, kind of unclear; what anchor?
***
In section 5.4.1 it is permitted to assign a single hexidecimal key
value to multiple symmetric ciphers. This poses an interesting
problem, since some symmetric ciphers (DES) have structure to their
keys (i.e. embedded parity bits.) Must implementations generating
inband DES keys have parity bits set appropriately, even though this
would reduce the utility of using the same key for something like RC2?
Should implementations check these parity bits and complain if they
are wrong?
I'm inclined to say we just ignore the parity bits, right or wrong, so
that the same keys can be used for all various ciphers. This is
probably what existing implementations do, but should be explicitly
spelled out somewhere.
***
In section 7.2.2 the NONCE description references section 4.5. There
is no section 4.5; it should reference 5.5.
The CRYPTOPTS description is not sufficiently precise as to what
headers are and are not allowed. The text suggests only headers
defined in section 4 are permitted here, which does not mesh with
current practice. If I understand properly, the headers allowed are:
- All negotiation headers from section 4.
- All new HTTP headers from section 5, except maybe Nonce-Echo.
but not, say, headers defined in section 2, which wouldn't make sense
in this context. The spec should say this.
***
Section 7.3 keeps the rather unpleasant convention of base64 encoding
an RFC1485ized DN. If we want to keep this the way it is for the
current version of the protocol I guess I can understand that, but
certainly we'll want to do something better in the long run, like
base64 encoding the DER of the DN.
***
Anyway, hope the discussion in Stockholm is useful, though alas I
won't be there. I must confess I'm not highly confident this will be
suitable for submission to IESG by December.
- Marc
--
Marc VanHeyningen marcvh@spry.com
Disclaimer:
If this were an official announcement from Spry-CompuServe Internet Division,
it would have begun with the phrase "FOR IMMEDIATE RELEASE."